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MBMS Support in UTRftW £ 

BAqrcQHeraa0 of the iKv^iirraaK 

MBMS (Multimedia Broadcast aad Multicast Services) is 
5 . currently being standardised in 3GPP - However, no real 
discussion took ever place regarding how to support the 
establishment of an MBMS session with regards to the UTRAN 
and in particular the lur- interface - 

The requirements for the MBL4S Service Architecture are 
10 " described in 3GPP TS 22.1.46 V..5.2.0 dated March 2002 . 
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Figure 1 shows a multicast group with user equipments that 
are controlled by different KNCs/SGSNs, 

15 Figure 2 ©hows a separation of a the lu control jilane and user 
V. plane a® suggested by the present invention. 

. ; Figures 3a and 3b show the necessary signalliri^ .betweeci SRNC 
and dfnc to iir^lement this s^rparation.. 



20 vBscRit&vzcM of wm iswmvxom 

It is a basic concept in MBMS that, the WM£ content is going 
to be delivered per multicast group members located in the 
area controlled by a certain 3NC and not pea: UE; 

On the other hand, when it comes to the * mapping' of this 
25 concept to the actual signalling and the currently adopted 
concepts in the OTRfcN there are different possibilities. 
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Within the UTFAN an RMC can take up different roles, e.g. as 
a Serving Radio Network Controller (SRNC) , a Drift Radio 
.Network Controller (DRNC) , or a Controlling Radio Network 

Controller (CRNC) . l*his has consequeaices on the MBMS 

.•*•• 

5 architecture, which have hitherto not beiag considered as it 
is only presvaned that the MBMS content is generieally 
delivered to an RNC* 

in particular, when aseiamincr a scenario where the lur- 
, interface is present and the MBMS session is going to take 

10 • place in a cell controlled by ths DfcNC therje will be a 
certain number of user equipments CUB) in that cell 
belonging to a multicast group interested iix that MBMS 
^delivery', some of which have the CRNC as SSNC and some of 
which are controlled by one or more SSNCs that are 

15 different from the CRNC. This situation is described in 
figure 1- \\ : 

In the sce^ariii as shows in frig-ure 1, there aria two options 
. when it comes to the delivery of MEMS content to RNC2: 

It is a first option that the content Is delivered, i.e, the 

20 Iu user plane for MBMS l& established, towards RNC2 

directly- In this cawe w© can say that fox- MBMS the Serving 

'.GPRS Support Node (SGSN) is always connected to the CRNC. 

t ■ * • • 

it is another option that the user piano for MBMS is 

established on an individual basiis vie\ the SKNC of each 

I * 25 member of . the multicast group. r ihii3 c&ses would ingply that 

:. there are MBMS user planes over the lur interface. 

It can be sera that with the seconi option there would be 
multiple unsynchronised flora fox the same MBMS session 
reaching RWC2, which is not desirable* For this reason it is 
Y 30 believed bianeficial that thta MBMS content is delivered to 

' the CSNC Eacli SIVXC would still receive MEMS RAB assignments 
from the relevant CN noda for the group members it is in 
charge of via the ordinary Iu interface as only the SRNC is 
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son 

fully aware of its own U2s, but the $L3M8 RftB will possibly 
logically be associated with a user plane . wiiich is 
established, towards another KtfC. 

On the other hand we should consider the case that, for 
5 exarople, UE1 is the oaly MBMS multicast group idiaidber in the 
cell for a certain session. Then, it r^ould be beneficial to 
use dedicated resources* for this UE. In this case it would 
also be better to have the content delivered over- lur as 
today, with all the gains, £K<m tba possibility, e.g., to 
10 make a soft handover, to gain capacity, <stc. 

Then with this approach, the ecursnon MBMS resource 

becomes available in tha c^l.L, e-g- *rh«?n wany multicast 
. group mentbers enter the cell,, the PPJKfC would indicate that 
• to the SRNC, which may choose to move the- UE to that 
15 resource. 

Thus, it has been observed to be a problem that there is 
currently no standardised mfcchani&xa within the UTRAN to 
attach the users to a. MBHS session when the lur interface is 
present. Xn addition to this it has nevmr been considered 
20 that it could be beneficial 1;o delivex the MBMS, content to 
the CKNC instead of the SRNC 

It is an object of fche present invention to avoid multiple 
uinsynchronised flows for the same K&MS session reaching the 
CRNC when there are multiple MBMS users, which are 
25 controlled toy different RNOs*, in the saw© session and in the 
same cell, orb© solution according th© present invention 
-; is. that in this case the Xi; user pLane delivering MBMS data 
is established towards the CKNC and not the SRMC. 

With this invention, the- CRNC will. initiate the 
30 establishment of the lu user plans* narrying MBMS data when 
there are sufficient users for that MBMS multicast session 
in cells under its control, The de^ail^d signalling over the 
lu interface is for further study, but the figure 2 
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; describes the principles , i.e.. the s<aparate control and user 
. planes could also be towards different Seeing GPRS Support 
Nodes. 

More over, in case for radio efficiency purposes * dedicated 
5 resources are to be used in tSte DRKC/CK&C controlled cell 
for users belonging to other M*Cs, a solution is that in 
this case, the MBMS content in delivered via lur as of today 
f oa: ordinary dedicated channels - 

With the assumptions above described, it can be saen that 
10 hew mechanisnuj. are required ovur the Xur- interface in order 
to enable the user equipments that are controlled by an RNC 
that is different from the one controlling the MBMS cell to 
join a certain session. 

In particular, then-:* is ei need to trsirisfer the MBMS RftB 
15 information coming Krcm the to the BHSC, i.e. the CHNC 
\ for the MBMS cell, so that Umi DRNC can attach such an UE to 
• . • the MBMS session. She J>TO3C should theft return - to the SRNC 

the information on the actual :resourccis allocated to the UB. 

If these resources are coiraiion, the DRNC wcyuld already have 
20 or has to establish an Iu user plane for MBMS and there 
should be an indication that no MBWF? content needs to be 
delivered to the SRNC. 

.This invention proposes a ivm set of elementary procedure 
:£or the KNSAP protocol, called Multicast Attach and 
25 Multicast Detach, 

The name of this procedure should be seen as a possibility, 
however, embodiments of the present invention can be 
considered any procedures enabling the below described 
. . mechanisms , 



30 



The procedure is started fi~om the SRTMC by issuing a 
MULTICAST. MKNSE RBQfDES'P message and thn suecessuful outcome 
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message is sent back front the DRS3C by means of MULTICAST 
ATTACH RESPONSE, as seen :.a figure 3a. 

in the request messeige the SKNC, beeoaw* a^fare that the UB 
wonts to join a certain MBMS ee.esion in a cell in the DRNS, 
5 is requesting the DKNC to attach the user to that session. 

At this point the decision of using dedicated or common 
resources is not xna.de yfifc. In the Multicast Attach Request 
message the SRNC will both r&lay BAB establishment-related 
information cooinir*g .Exam the Core fifetmurk and information 

10 similar to what is currently included i:a the Radio Link 
Setup/Addition Request messuagra in cas® dedicated resources 
are to be established, for this; UE. The SSSC is not aware if 
this is going to happen, it is a D.RNC decision. It could 
also be possible to include in this ffusssage a flag where the 

15. SKNC indicates its willingness to jraov& che UE to common 
resources when the Dr<NC becomes aware that common resources 
^re more appropriate for th.:i«; HOTUil session. The relevant 
MBMS session identifier to at:bach the UE t.o is also included 
in the request, messa^a,, 

20 Once the DR3KTC receives this in format Ion, &r\di being aware of 
how many users are bound for that MBMS session in that cell, 
it can decides whether to allocate dedicated resources to 
this user or not- If it decides so, the K)M$G will establish 
: the relevant resources and retusra a MULTICAST ATTACH 

25 RESPONSE message which in this cas© mmld be basically 

* analogous to the Radio Link Sutup /Addition Response, message. 

• * *- 

: If the DRNC decides to alloc-ite common resources - and the 

SRNC was willing to allow that US on coiron resources - it 
, : : will establish an lu user plane towards th* appropriate SGSN 

30 (in this case it is likely that an lu user plane for the 
[[[: MBMS session already exists) and ration the MULTICAST ATTACH 

RESPONSE message cant-aiaiaa- tlxe reformation about the 
established common rasourceis and Xu user plane, so that the 
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: SMTC is informed that the t£3MS- data for this user is being 
delivered via -:he DRNC. If the procedure was not successful, 
the DBNC shall include relevant information, e.g. cause 
. values,, etc., in a MD&TXCTkST ATTJiCH FATXTJRE message. V 

5 In order to enable the SRHC to remove the UB from the 
session a corresponding MC DETACH procedure can he used. 
Details are for further study, 

When channel switching from dedicated to conaaoaa resources is 
to be performed, the DKNC can i-ndicate (knowing from the MC 
10 . Attach procedure that this (JE can be moved to common 
resources) the need for a switch to the SHNC in a 
appropriate message M33MS XNFO^lATIOJtf TRM3SFER INDICATION 
(that could be used to relay a.Lso other MMS related control 
information needed at the SKNC) , as i*hown in figure 3b. 

15 The possibility of performing the Multicast Attach and MHMS 
..Information Transfer per pools of UEs controlled' -by the same 
, SWiC to reduce signalling ovetf lur is a possible option. 

It. would also be possible to feedback HBHS information via 
the already specified Information Exchange procedures. In 
20 this case the feedback exchange cannot be initiated by the 
DSNq autonomously, though/ therefore this would apply to 
background MBMS data retrieval more than to scenarios like 
channel switching. 
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The present invention provides the follo^xng advantages: 

The Iu MBMS user planes sire established where needed and in 
case of common resources being allocated for sseveral members 
of a multicast group receiving data in the same cell the 
presence of multiple iinsynchironised flows for the same MBMS 
session is avoided. 

30 It is another advantage that the invention introduces the 
heeded medianisnis in fcha jftff&AS protorol to enable users 
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controlled by a KOC different from the CRNC <Iur scenarios) 
to participate in a MBMS multicast session. 

■ It is yet another advantage that the invention evolves the 
current UTRftN architecture in a backwards conpatible. way and 
5 maintains the current handling in case of dedicated 
resources. 

It is still another advantage of the invention to introduce 
a new procedure (MBMS Inforovation Transfer) to enable the 
signalling of MBMS information feedback between two BNCs 
10 connected via a lux interface. 

The present invention claims a separation of the MBMS lu 
control and user plane suad related concepts and possible 
ranap and/or other new or existing protocol signalling; 

It claims further Multicast Attach, Multicast Detach and 
15 MBMS information Transfer pre endures an<'. related concepts or 
any. differently namrad Xur procedures realising the above 
described, mechanisms - 

The present invention also claims the possibility of 
relaying MBMS related feedback <nsw Information ■ Elements) 
20 via the already specified Information Exchange procedures 
(if MBMS Information Transfer or similar procedure is not 
. adopted . 

The present invention a« described above targets the 
Multicast Mode of MBMS; however, after due modifications, 
25 these concepts could also be applicable for the Broadcast 
•Mode of MBMS. 
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Fig. 3a 




Transfer IcnlteettJ-ira 




Fig. 3b 
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